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Patent for 'A Universal Database Schema* 

i*S^3E2£ ^ ° f "" ° Vera " database des ^ tab.es and fields, 

ta.'^£S r 2 < f SITS. 18 3 te T oojned to mean lhat «» schema is highly flexible in how it can 
be used, and that schema changes are not required to store new classes of date 

c i ^! a K? dard f* ema ' uses a teb,e for eat* class of data to be stored fie A Clients fable with 
This patent descrttes a particular confisuralion of Onhwrea) Schema (or database design) 

UnnSS^ pres ?" ted here P rav Wes a model that could be used for every one of these 
applications, providing a vast array of advantages. 

^^^^.r^h^r^^o, 

Merits of this Universal Schema over a Standard Schema 
Hierarchical storage model for all data 

The Windows'™ Explorer / file system and Windows™ manaaement consoi* =«, „ri m „ 

This Universal Schema enables hierarchical data storage at Its core. 
A consistent storage model for all data 

and coda Is required that «s the tat*, ,„ ql 2SS in'^IZ^SiS^""* 
Maximization of code re-use 
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The Forms section of this Universal schema further supports code re-u SS m the .k . 

nSSTfiST pro * de ed * ng and *^*tt2lSSE£* m 

sd^Sa^h C angr S * introduced ' cnan 9 ed or deleted without 

deve^Jm^^ SlI 965 a ^ntfor a signfficant percentage of 

uBveropmeni overneaas. Estimates in my experience range from 40% to 75%. 

'"?,?^ ndard schema, every single new table anoVor field introduction or modification in » 
SaS dSr 31 SChema " SCh6ma Chan96S are not re 1 ulred to change or delete 

Any field can store multiple values 

A standard schema might have a client table with a phone number column or field If vou 
Any field can store a history of changes 

^ri s o c a 

A direct relationship may be created between any data classes 
without schema change. 

Snnewi^ 0,6 9 ' ue 0,31 no,d wWonal databases together. Whenever new tables or 

SS^JSSSXSX' 6 , " aSta 2 d t ard schema ' additonal relaSfp^mSo te 
d?tatesl server *S"»* «* to provide vital data integrity services from the 

Adding, changing or deleting a relationship is also a schema change! 

Th^Universal Schema allows relationships to be created, edited or deleted without a schema 
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Extensive Meta Data is available for all classes of data. 

It is a very common requirement to associate 4 Meta Data' (descriptive or functional dat»\ «/*h 
any given field in a table, or any given table within a database 31 wrth 

Examples of meta data for a field may be: 

DlSton fie,d namB WHWn databases ,s a restrlcte <* system name) 



Format 
Read only 
Required 
Edit Control 
Etc 



fcWittfiSSXSSZ ZEST" of 8torins such meta data 

In this Universal Schema extensive meta data is built in for every data class and field. 
While a change of schema is required to add meta data to fields in the current version thi<= fe 

?lddS re iSSS^V^T! *XS2** be ^A^easiS^pS^Sa^ 
deveioSn'e™ >- meth ° d °' mtrodudn 8 mete **» v^out schenia change is undS 
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Conventions used in this patent 
Table & Column (field) Names 

All Table & Column names are expressed without spaces and are capitalised at the beoinnino 
of each component word. le. EntftyType or ValueDate M 31 me De 9 mn 'ng 

The names are designed to describe the intended function of the table or column. 

Relationship columns 

Where a column points to the unique identifier column of another table, that column name will 
vSSmwSd. related tab,6S name folIOWed by ,,D ' ,e ^%TyS w 
This convention defines the table relationships in this patent 
All Tables use an Identity Column called "ID" 

S^wf?^^ Btl^T a 4 byte LONG ,NT EGER numeric ID column, it is also 
acceptable to use an 8 BYTE Curency or 16 BYTE QUID (Globally Unique Identifier). 

Required Columns 

Each table described will define a set of required columns. These columns form the core 
configuration to enable and optimise the stated features and claims of this pateSt 

Every table must have and identity column caned 'ID 1 which is not shown for each table 
Desired Columns 

Optional Columns 

Each table described may define a set of optional columns. 

Entity Resources 

^hff^if™, to d JL scribe 018 FieW and Va'"e records that have been defined for an entity 
and that must exist after an entity record is created. v ' 
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Describing this Universal Schema 

The sample schema diagram. 

V^^S^^S. dia9ram fe WwS " Un{v e»«a> Schema V2.8" and is marked as 
Copyright © 2003 Wolfgang Flatow & Weteon IT Solutions (21 * of March 2003^ 

ISZSST^&ES! fe supported fa y a P ri "tout of a sample schema (as used by the 
prototype). The database server is Microsoft SQL Server 2000 ™. 

The Table & Column names closely match those used in this patent, but are not identical 
^XStSST T- *" & C ° ,Umn8 88 d6fined ^ a " d ** SSSSi 3 Swn 

Tables shown on the diagram and not defined in this patent are: 

1. WebSession 

2. Log 

3. LogType 

These tables provide optional Web and logging services for this schema. 

The Data Storage System 

,ISi~?il e ^ a if Ch ^ na can manage 3,1 data wlh a sim P ,e En** ' Field / Value structure 
!?v2ua 0nS 85 the . 9 ' Ue b6tWeen the a FieldT yP e *■» defines ttlefield and 

fSff 13 f,* 51 ?! 6 ^ by providing a table for each Data Type that requires storage. 

2h ThT^i! aIU lT able 1' l ° n J for 6300 data *Pe. with a pointer totheir corresponding 
field There is no additional burden on the schema or performance when adding Value tables 
as the value tables point to the field and will only be requested if they exist 

^^^'""T 3 ' "J* are required using the EntityType / FleldType 

structure, where there is a FleldType record defined for every field that an entity require! 

The schema 'knows 1 what Value table to use for what field by the FleldType / ValueTvoe / 
DataType structure, where the DataType table points to corresponding v4lue Tables^ 

Mai I IB. ' 



When referring to the schema diagram the names of the tables are the same as those below. 
The Entity Table 

ISE? 1 u pll6S J an £ entit Y or anything at all that you may wish to store is represented 
by the entity. It provides the common interface to all items stored within this schema. 



Required Columns: 

• EntltyTypelD 

• ParentEntitylD (Self referencing pointer) 
Desired Columns: 

• Name 

• Ordering 

• EntitySatusID 

• CreationDateTime 
Optional Columns: 

• Locked 
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• LastModffted 

• Expanded 

SJcSJ? teb ' e fe 3 56,f referencin9 hfera "*'«> tabte that provides the 'skeleton' of the data 

The Entitles corresponding definition (or meta data) table is the 'Entity Type' table. 

An 'Entity Status' Table provides lifetime control such as created, active, deleted, archived 

fS^ n i niP «aWe Provides direct relationships not defined in the Entities hierarchical 
structure, by providing a FromEntity and a ToEntity pointer 

The Field Table 

stend^?slSrna the *** represents a tebte ' 0,6 fieW ^presents the Column of a table In a 

The field is strictly glue between the entity, field type, and correspondlno value of the field 
Other than the IsDeleted, LastModified aSd orderinjattrib^ 

Required Columns: 

• EntltylD 

• ReldTypelD 
Desired Columns: 

• IsDeleted (enable field history) 

• Ordering (ordering of 'multiple filelds') 
Optional Columns: 

• LastModified 

Its name (and all other field meta data) comes from Its corresponding FieldType record. 
The field can have 1 or more Value Table records pointing at it 
The Value Tables 

S C 5a V teT^2! e ^ 3 ~^ pomfin 9 * Dat aType table. They may also be called 

Required Columns: 

• FleldlD 

• A Value Column (see below) 
Desired Columns: 

• IsCurrentValue 

• DateTEme 

• UserEntitylD 

The desired columns enable a history of values to be kept 

The Value columns may be of any data type available within a given database Server: 

• Text Value (ValueShortText ValueLongText) 

• Boolean Value (ValueBoolean) 

• Currency Value (ValueCurrency) 

• Date/Time Value (ValueDate) 
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• Binary Large Object Value (ValueBLOB) 

• Entity Pointer Value (ValueEntity. ValueEntityType, ValueForm etc) 

• Other Value ' 

Note: These could also be called DataBoofean, DataDate etc. 

The Data Definition Structure 
The EntityClass Table 

Thiste an optional table, and provide grouping and hierarchical services for the EntityType 

Required Columns: 

• Name 

• ParentEntityClassID (self referencing) 
Optional Columns: 

• Description 

The EntityType Table 

r y J*,* 8 E ? ti ^ ls a referencing hierarchical table, the Entity Type 

tSSSSZS. Tefe ?£ ,ng hlerarchicaJ **• •* ^flras the mandatory ^default * P 
hierarchical structure of its corresponding entities. 

The Entity Type provides the 'skeleton 1 of the data structure definition.. 

Required Columns: 

• Name 

• ParentEntftyTypelD (self referencing) 
Desired Columns: 

• EntltyCiassID (pointer to the EntityCJass table) 

• Ordering (provide entity ordering between child entities) 

• IsFofder (True if the entity is a 'container- for other entities) 

• IsCreatable (can users create this type of entity?) 

• IsFlxed (can this only exist under my parent type?) 

• IsDefinltlonEntity (see below) 

• Help 
Optional Columns: 

• NodePrefix (used in populating treeviews) 

• HasProcessForms (used to determine processing forms) 

• Enum (generate enumerated values) 

T^l m[ ^ nB Z n T m This !, c ^ ema stores Items normally stored in 'lookup tables' in the Entity 
E^^^IW Entit y T VP e this kind of function it should be labelled as a 

££ data s&g^ 6,PS to dlStin9Ulsh ent!t,eS 0f «° m entities usld for 

The FieldType Table 

woh ^Z* 3 ^"* ?S?J S * e maln entit V ^source definition, providing a record for everv field / 
Value pair required by all Entitles that have this FieldTyp^s EntityTypelEX rorevery 11613 ' 

Required Columns: 

• Name 

• EntityTypelD (The EntityType this FieldType belongs- to) 

• ValueTypelD (The VaiueType of this FieldType) 

• FormatID (The display Format to be used) 
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• a dropdown fBter of EnBaes by vaM ** 

• ^S^ISSSST^ 3 dr ° PdOWn fifer ^ * D * Bn ° f 3n EntHy - VaBdft * 

• Is Local (WBi not be created at entity creation - see below) 

I inhS ? ?T °! a " 1 J? ,d 0f thfe ReWT W« ma y be created - see below.) 

Desired Columns: 

• Ordering 

• tnputRequirad 

• DefauItValue 

• MinimumValue 

• MaximumValue 

• IsEntttyDefault 

• Help 
Optional Columns: 

• ^!? Mu ^ p, . e < Defines an M "l«Ple Fteld with a fixed number of Multiples that are 
created on Entity creation. Works with MuIHplesToCreate below) * 

' 55B53l^^^ n^berof multipiestocreate for either .sMuitipteor 

SiSffJ?. 18 , defi ?5 S a fi f ld for an entft y ^ may or may not be required. Entity Resources 
^^s'sLocal do not get created when the entity is created. Some o*er Sto 
determined by users or code may create or delete this fieWL 

teMultlple: This defines a ReldType that can have 0 to n Fields for any given Entitv 

SSSKfiK"" ,sMulB P'L d0 not 9 et created **» S«S3.~2L other 

ReloTy^e V * m3y C,Bate 0r de,ete numb * r of fields of Ss 

The VafueType Table 

The function of the ValueType table is to "Type" the ReldType. 

Required Columns: 

• Name 

• DataTypetD 
Desired Columns: 

• FormatID 

The DataType Table 

The function of the DataType table is to link the FieldType/ValueType structure to the 
Required Columns: 
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• Name 

• TableName 

• PrimaryDataFieldName 
Desired Columns: 

• DefauftFormatlD 

• DefauJtControIlD 
Optional Columns: 

• AccessName 

• SQLServerName 

• VBName 

^XSl^^ S ° me ^ f ° r dWe,0PerS t0 deslred ^ *» 

The Format Table 

Ffe?dTyp£ teb,e 3 S6t ° f diSplay formats for use b y DataTypes, ValueTypes and 

Required Columns: 

• Name 

• Format 

• DataTypelD 

Composite Field Type 
This is an optional table. 

The purpose of this table Is to allow more than 1 Value table to store a value for a given field. 

5en a d2te ti^ ,Ue €aCh ValUe TaWe t0 te 5t ° red f0r e3Ch field ' but not more *« 1 of a 

Required Columns: 

• Name 

• FleldTypelD 

• ValueTypelD 
Desired Columns: 

• FormatlD 

The columns here may be built up to include most of the FieldType columns. 

The EntityStatus Table 

The EntityStatus table controls the lifecycle of an Entity. 
This would typically include: 

1. Created 

2. Active 

3. Withdrawn 

4. Marked for Archiving 

5. Marked for Deletion 

6. Deleted 

Required Columns: 

• Name 
Desired Columns: 

• Description 
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The Relationship Table 

eSfSSSSS^ relati ° nShiPS b8tWeen entities ** «■ not ^enA/fee catered for by the 



Required Columns: 

• RelationshlpTypelD (see below) 

• FromEntltyiD 

• ToEntitylD 
Desired Columns: 

• EntltyFieldEntitylD 



Thfe^ provides a very versatile set of functionality in this schema. For example tfvouneedto 
perform processing on certain branches of the Entity Hierarchy, RelaSSS^Se ^d 
SSS^™** **5 a " 0WS * "randi without the neeS fa Hg toe 

reSSip^ 9 t** 0 ™™ 0 *- « also be used for any Grouping or cSshfp 

The RelationshipType Table 

This ; table Provides a Type 1 for the Relationship Table (see above) as well as orovidino 
EnbtyType, EntrtyClass and ReldType Relationship services e;aswe,,as Priding 

»MinS£ K^ Pe °L e ^ S °° nnected U5ln 9 *e Relationship Table and/or define 
relationships between EnbtyTypes. EntrtyClasses, FieldTypes and Entities. 

Required Columns: 

• Name 

• RerationshlpGroupID 

• FromEntityTypelD 

• ToEntltyTypelD 

• FromEntityCiassID 

• ToEntityCfasslO 

• FieldTypelD 

• EntitylD 
Desired Columns: 

• EntltyFieKdEntltytD 
Optional Columns 

• Description 

• Enum (generate enumerators) 
The RelationshipGroup Table 

tab£? nSSSSSS^SS a,S ° be f ed to define Unships between definition 
tables, the RelationshipGroup table serves to group the RelationshipType Table entries. 



Required Columns: 

• Name 
Optional Columns 

• Description 



The CompositeEntity Table 

?e?^ *"* » "* schema- that of sharing or inheriting 
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Forexample, If numerous EntityTypes where participating in process control then process 

be shared by any other EntityType by an entry in this ComposrteEntity Table 

In this way an EntityTypes FieldTypes may be bunt up of several shared •composite 

EntltyTypes and may or may not have any native FieldTypes itself. 

Required Columns: 

• Name 

• CompositeEntftyTypelD 

• FromSourcoEntityTypelD 

• ToTargetEntityTypelD 

Composite Entity Type 

£^ C^POsiteEntity records, and to provide a pointer to dedicated 

Required Columns: 

• Name 

• SourceEntityTypelD 
Optional Columns 

• Description 

Forms 

I^Vm^^Sln iSffJ 0 82"*^ ^ numer ? us dfeP^ and processing services for this 
schema It is, again, a highly flexible and generic structure that may be used for. 

• Generate any number of views or forms of an Entities data 

• Independent naming, formatting and controls display for each form 

• Defining fields to display in browse lists 

• Defining fields to display in reports 

The Form Table 

This table contains one record for each defined Form. 

SiTn5t™ y . a8S0C ? te . d ^ th an Enti * T ype that supplies the FieldTypes to dispfay, but 
this is not a requirement A single Form bay combine FieldTypes from any EntltyTypJs. 

Required Columns: 

• Name 

• FormTypeFD 

• DataEntityTypelD 

• FormTabID 

• IsDofaultForm (default form for the DataEntityTYoe) 
Desired Columns: * r ' 

• TargetFormID (Define form sequences) 

• SubmitButtonText (If other than 'Submit) 

• VaNdateForm 
Optional Columns 

• Description 

The FormType Table 

This serves to group Forms and to define Form Function. 

For example, you may have FormTypes of Edit, View, Browse, Report etc. 
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Required Columns: 

• Name 

• FormTabGroupID 



The FormGroup Table 

I^Hf!^ ^ pT °y l uft 9 rau P^9 of FormField records for each Form. For example, in 
a Stock Item Foim you might have a 'Details*, a •Suppliers and a "Locations 0 group 
FormGroups also serve to group one or more 'multiple FieldType , values. 



Required Columns: 

• Name 

• FormID 

• Ordering 
Optional Columns 

• Enum 



The FormFietd Table 

This defines the FieldTypes to display, their names, format and editing control 
£ Ca, ie?! ,,y be extended to contain default, minimum, maximum and validation information 
tor each FormField. 



Required Columns: 

• Name 

• FormID 

• FormGroupID 

• FieldTypelD 

• ControlTypelD 

• Ordering 
Desired Columns: 

• InputRequired 

• VIewOnly 
Optional Columns 

• Enum 



The ControlType Table 



This defines the different editing or display controls that may be used to edit or output data 
For example, it would contain an entry for text editing control, a checkbox, a radio button etc. 



Required Columns: 

• Name 

• Width 

• Height 

• MaxChar 
Desired Columns: 

• NetscapeWldth 

• XSL 



The FormTab Table 

Ks^JJgrolip^ 6 ° neS commonly shown a,on 9 toe top of a form to provide a link to other 
This is used to define a set of tabs, grouped by FormTabGroupID fields 
A Form can then be associated with a FormTab 
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Required Columns: 

• Name 

• Image 

• FormTabGroupID 



The FormTabGroup Table 

This serves to group FormTabs. 

Required Columns: 
• Name 
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Claims 



Claim 1. The Universal Data Storage System 

I claim the invention of the universal data storage system defined as: 
Hierarchical Entity Table / Field Tabie / Data Tables 

Where the Entity has a self referencing parent pointer that allows a hierarchy to be defined 
where each Entity has zero or more Fields and each Field has at least one Data Table entrv 
In one of the Data Tables. 7 
Where there is one or more Data tabie for desired (or all available) Data Types and any 
desired pointers to other database objects (le Entity, EntityType, Form etc). 
Allowing more than one Field of a given FieldType for an Entity. 
Allowing historical data to be stored in each Data Table for a given Freld. 

Claim 2. The Universal Data Definition System 

I claim the invention of the data definition system to support the Universal Data Storaae 
System in Claim 1, defined as: 

Hierarchical EntityClass Table (optional) / Hierarchical EntityType Table / FieldType Table / 
ValueType Table / DataType Table 

Wherethe EntityType has a.self referencing parent pointer that allows a hierarchy to be 
defined, where each EntityType has zero or more ReldTypes and each FieldType has one 
VafueTypes, each of which has a DataType. 

Providing a system of automated construction of Entity, Field and Data Records 
Providing extensive Meta (or descriptive) Data for each Entity and Field. 
Providing a system of data class definition without the need for schema changes. 

Claim 3. Combination of Claim 1 & Claim 2 

L^ro^!? invention of a Universal Data Storage & Definition Schema that combines Claim 1 
<* Claim 2. 

The resulting schema having the capacity to define and store any conceivable data class 
(normally requiring a dedicated table) without schema changes. 

Where Database Views 1 can be automatically generated for any of the EntityTypes defined in 
the schema that provide a 'standard 1 or 'flat table from the universal schema. 

Claim 4. The Universal Forms System 

I claim the invention of the Forms Definition System defined as: 

FormType Table / Form Table / FormGrou p Table / FormField Table with a correlating 
FormTabGroup Table / FoimTab Table structure. 

Where each Form is of a given FormType and has n FormGroups, each with n FormFields. 
Where each Form can be linked to a EntityType. 
Where each FormField Is linked to a FieldType. 

Providing a system of defining any number of form views of an EntityTypes FieldTyoes fwith 
data from a conesponding Entities Fields). 1 
Providing a system of defining any sets of FieldTypes for browsing, reporting etc purposes. 
Providing a layer of abstraction that allows data labelling, display and processing to be 
defined for each Form. * 

Claim s. Combination of Claim 3 & Claim 4 

I daim the invention of a Universal Data Storage, Definition & Display Schema that combines 
Claim 3 & Claim 4. 

The resulting schema provides a comprehensive range of services allowing complete 

applications to be built without need for schema changes. 

The range of potential applications for this schema is claimed to be- 

EVERY APPUCATION REQUIRING A DATABASE 

That is, it is always an option to utilize this schema instead of designing a standard schema. 
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This schema also provides many opportunities for a powerful database services layer 
Including Entity creation and destruction, data access, hierarchical services etc. 
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Composite Entity Types provide 

field definitions that can be re-used by 

other Entity Types 
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Value Type 
provides a layer of 
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